\chapter{Motivações}

Este capítulo contém as motivações e inspirações desse documento, seu objetivo é mostrar ataques relacionados e a situação atual da segurança de 
redes em relação a ataques de negação de serviço envolvendo SSL/TLS. Serão mostrados ataques que inspiraram a confecção do
novo ataque e expectativas de possíveis resultados e impactos baseado na situação atual da segurança digital.

\section{Objetivos e Código de Conduta}
Como já mencionado, a confecção das ferramentas de ataque deste trabalho não tem como objetivo causar mau, e sim verificar a possibilidade do ataque
para assim alertar aos interessados sobre sua existência. Muitas vezes é difícil prever novas formas de ataque de negação de serviço,
no geral, é necessário primeiro conhecer o funcionamento do ataque para assim planejar uma solução ou mecanismo de defesa. Esse documento
tem o objetivo de facilitar a construção desse mecanismo de defesa, mostrando abertamente como um ataque de negação serviço usando TLS/SSL
funcionaria em diferentes estados criptográficos, inclusive o \emph{Perfect Foward Secrecy}.

Nos próximos capítulos, pretende-se mostrar claramente detalhes da implementação do ataque e como seus testes foram realizados, para 
assim deixar claro seu funcionamento, seus efeitos e impactos nos servidores. Para tentar impedir o uso incorreto do ataque, todos os
artefatos e códigos gerados para a confecção desse documento serão mantidos confidencialmente entre o autor e o seu orientador.

Em suma, o objetivo deste documento é o desenvolvimento de ferramentas que causem um ataque de negação de serviço contra servidores
\emph{web}, analisando todas as possibilidades de ataque por exaustão de recursos computacionais. Para exaurir esses recursos, serão usadas conexões
seguras(TLS/SSL), mostrando que mesmo conexões seguras podem ser a causa de um ataque, não sendo totalmente confiáveis. Os ataques, então,
serão testados em ambiente controlado(fugindo do enquadramento de crime cibernético) contra servidores com TLS/SSL. Os resultados servirão
para avaliar a viabilidade do ataque demonstrando sua funcionalidade e medindo seus impactos no cliente e no servidor.

\section{Ataques relacionados}
Uma das inspirações deste projeto foram ataques passados que usavam de SSL. Um desses ataques e um dos primeiros a usar SSL foi o ataque
de renegociação de chaves. Esse ataque abusava de uma opção do protocolo TLS/SSL e do custo computacional associado a ela~\cite{thc}. 

Como mostrado em capítulos anteriores,
cliente e servidor podem gerar chaves de sessão usando diferentes mecanismos, porém essas chaves são geradas durante a criação da conexão.
A geração dessas chaves gera um custo computacional devido ao trabalho criptográfico envolvido, e normalmente só ocorre uma vez, durante a
criação da conexão segura. Mas como previsto nos protocolos, o cliente e o servidor envolvidos numa conexão segura usando TLS/SSL podem renegociar chaves.
O ataque consistia de uma sequência de renegociações de chaves~\cite{thc}, onde o cliente não calculava sua chave mas exigia do servidor sua nova chave.
Essas sucessivas renegociações exigiam muito do servidor e causavam exaustão, numa renegociação normal o gasto computacional do servidor
é 10 vezes maior que no cliente.

Pode-se perceber que o ataque usa de uma opção viável pelo protocolo para causar a negação de serviço, tal como pretende-se fazer com
as ferramentas criadas nesse documento~\cite{thc2}. Esse ataque é praticamente obsoleto, pois uma solução foi amplamente adotada pelos servidores
da internet. Embora o protocolo TLS/SSL não tenha sido alterado, os fabricantes de software de servidores \emph{web} criaram atualizações
nas quais clientes não mais poderiam renegociar chaves, apenas servidores. Essas atualizações diminuiram a força do ataque, provando-se uma
solução eficiente, tal qual pretende-se inspirar com este documento.

Um outro ataque bem similar ao descrito, foi o ataque proposto por Vincent Bernat em seu blog~\cite{vincent}. Estudando técnicas para mitigação do ataque de renegociação de chaves,
o autor percebeu que o custo computacional de decifrar uma mensagem pelo servidor é mais caro que o custo de cifrar. É de conhecimento
popular em criptografia assimétrica que o custo de cifrar e decifrar variam, mas devido ao funcionamento dos protocolos de
segurança e a forma como certificados funcionam, o servidor quase sempre terá um maior custo para decifrar. O autor então sugeriu a possibilidade
de criar um ataque onde o cliente não cifra suas mensagens e sim manda um 'lixo' qualquer. O servidor
tem que decifrar a mensagem para então perceber que se trata de 'lixo', logo o cliente não tem custo e o servidor arca com o custo de
decifrar.

Espera-se que usando algumas das sugestões propostas por Vincent Bernat~\cite{vincent} que se possa confeccionar ferramentas para o ataque. A idéia
do ataque proposto neste documento
consiste em mandar mensagens com 'lixo' ainda durante o \emph{handshake} TLS/SSL, para que o servidor tenha uma maior custo. Partindo
da idéia geral dos DoS, a vítima tem que consumir mais recursos do que o cliente gasta para atacá-lo. Propõe-se, então, a construção
de uma ferramenta que usa desse desequilíbrio, para com um baixo custo no cliente causar um grande consumo no servidor e consequentemente o DoS.

Além desses conceitos pretende-se também avaliar o uso de diferentes \emph{cipher suites}, testando quais possuem um maior custo para o servidor,
assim aumentando o desequilíbrio. Comparando as diversas \emph{cipher suites}, verifica-se que um dos mais populares protocolos de negociação de
chaves é o RSA, porém o protocolo estava envolvido em recentes polêmicas envolvendo a NSA(Agência de Segurança Norte Americana)~\cite{nsa}~\cite{nsa2}.

O último escândalo envolvendo a NSA deixou transparecer que a agência estava espionando cidadões e empresas na internet, monitorando
e gravando 
suas conexões, 
descobrindo informações privadas. Estudiosos de criptografia então começaram a recomendar o uso de conexões seguras, porém ficou 
claro que
se a agência americana estivesse de fato armazenando dados transmitidos, o protocolo RSA não seria mais confiável~\cite{nsa2}~\cite{pfs}. 
O protocolo RSA não seria mais seguro pois no protocolo são usados um par de chaves que não costuma variar, por mais que as chaves
sejam computacionalmente seguras, a NSA usando vários computadores pode dentro de um longo período quebrar a chave. Mesmo que a quebrar
das chaves demore, uma vez quebrada a NSA poderia decifrar todas as mensagens que já possue armazenadas.

Com essas preocupações em mente, o \emph{ Perfect Foward Secrecy}(segredo perfeito) ganhou um lugar especial na comunidade. O \emph{foward secrecy}
consiste em usar uma chave diferente para cada conexão, para isso usam-se \emph{cipher suites} que usem do protocolo Diffie \& Hellman efêmero,
tanto na versão normal quanto na versão com curvas elípticas, pois ele garante que as chaves serão transmitidas seguramente entre cliente e servidor.
Com uma chave diferente para cada conexão a NSA ou outro possível atacante teria que quebrar as chaves de cada conexão, o que seria
computacionalmente inviável~\cite{nsa2}~\cite{pfs}.

Mas o \emph{Perfect Foward Secrecy} também envolve um maior custo computacional já que chaves devem ser geradas e negociadas a cada conexão,
logo esse custo computacional extra também pode ser usado por um atacante, como neste documento. Nos testes das ferramentas de ataque
pretende-se testar o uso do \emph{Perfect Foward Secrecy} para mostrar que seu uso não é a solução perfeita pois o mesmo traz desvantagens~\cite{pfs}~\cite{nsa2}.

Tendo-se em mente todos essas ferramentas prévias e o conhecimento desses fatos, planejou-se esse documento com a intenção de testar 
a possibilidade de ataques de negação de serviço envolvendo TLS/SSL como contribuição para a área de segurança de redes. Criando uma 
vantagem para a área de segurança antes que ataques desse tipo começem a acontecer.


\section{Contribuições e contrastes}
A contribuição deste documento, em suma, é testar novas estratégias de ataque que podem desencadear um novo ataque de negação de serviço, 
analisá-lo, expor os resultados e mostrar conclusões a respeito de sua funcionalidade, possíveis idéias de mecanismos
de defesa e outras melhorias que um possível atacante pode adotar.

A proposta do novo ataque difere de ataques semelhantes pois consiste da combinação desses ataques junto com melhorias, em busca de um melhor 
desempenho. Combinando as idéias de Vincet Bernat ~\cite{vincent}, ataques de DoS famosos, \emph{benchmarks} de \emph{cipher suites} e o 
ataque de renegociação de chaves TLS/SSL,
pretende-se criar um ataque que seja viável e funcional em servidores \emph{web} atuais.

A primeira idéia para o ataque é usar conexões completas, no ataque de renegociação de chaves a conexão é reiniciada antes de
ser completada, pois o cliente requere uma nova chave propositalmente. Como a renegociação não é mais possível por parte do cliente, a
solução planejada é deixar a conexão ser estabelecida e então refazê-la do início, ao invés de requerer uma renegociação.

Outra diferença no ataque planejado é tentar estabelecer uma maior diferença entre o consumo de CPU do cliente e do servidor. Caso o consumo
de CPU do cliente seja bem menor que o do servidor, menos clientes (e possivelmente menor poder de processamento) serão necessários
para exaurir o servidor. Esse desnível presente em muitos ataques de DoS é essencial pois servidores geralmente são robustos quando comparados
a computadores pessoais (atacantes). 

Para alcançar esse desnível pretende-se usar a idéia de Vincent Bernat em seu blog ~\cite{vincent},
mandar a mensagem final (\emph{encrypted handshake message}) do processo de \emph{handshake} com 'lixo'. A mensagem final do \emph{handshake}
consiste de um resumo cifrado de todo o \emph{handshake}, o servidor precisa decifrar a mensagem (gasto computacional) para ver se o resumo
confere, mas o gasto computacional de criar \emph{bytes} aleatórios(lixo) pelo cliente é zero. Um maior desnível entre os gastos de CPU
deve ser alcançado usando essa idéia e testando cifras que sejam mais onerosas computacionalmente. Outras estratégias também serão 
avaliadas
em busca de tornar o ataque mais eficiente para que possa ser testado.

Além das contribuições citadas, pretende-se realizar testes de versões do ataque com \emph{Perfect Foward Secrecy}. Como o uso do protocolo
Diffie \& Hellman efêmero começou a ser sugerido e enaltecido pela sua maior segurança ~\cite{nsa2}, o mesmo será testado para avaliar sua eficácia
e segurança em relação aos ataques de DoS.